1. Field of the Invention
The present invention relates to a cable modem termination system (CMTS) and a cable modem (CM) system in a hybrid fiber coaxial (HFC) network, and more particularly to, a method and apparatus for providing a CM with a plurality of burst profiles for an upstream data transmission via an upstream channel descriptor (UCD) received from a CMTS, and for allocating resources to the CM by using the plurality of burst profiles according to a data reception status through an upstream channel check.
The present invention is derived from a research project supported by the Information Technology (IT) Research & Development (R&D) program of the Ministry of Information and Communication (MIC) of Korea [2006-S-019-02, Development of Digital Cable Transmission and Reception System for 1 Gbps Downstream].
2. Description of the Related Art
FIG. 1 illustrates a conventional hybrid fiber coaxial (HFC) network 150 comprising a cable modem termination system (CMTS) 110 and a plurality of cable modems (CMs) 120. Conventional medium 140 constituting the HFC network 150 includes coaxial cable and fiber optic cable.
Referring to FIG. 1, the CMTS 110 transmits or receives a signal to or from the CMs 120 over the HFC network 150. Therefore, each user 130 transmits and receives data over the CMs 120. In more detail, the data is transferred via channels within HFC and coaxial cable, in which one of a plurality of channels is used to transfer a downstream signal from the CMTS 110 to the CMs 120, and another is used to transfer an upstream signal from the CMs 120 to the CMTS 110.
The downstream channel used to transfer a downstream signal from the CMTS 110 to the CMs 120 constitutes a bandwidth of 6/8 MHz within a frequency range of 54˜860/100˜860 in North America/Europe, and uses a modulation technique of 64 quadrature amplitude modulation (QAM) using a 6 bit symbol or 256 QAM using an 8 bit symbol.
The upstream channel used to transfer an upstream signal from the CMs 120 to the CMTS 110 constitutes a bandwidth of 0.2/0.4/0.8/1.6/3.2/6.4 MHz within a frequency range of 5˜42 MHz, and uses a modulation technique of quadrature phase shift keying (QPSK) using a 2 bit symbol, 8 QAM using a 3 bit symbol, 16 QAM using a 4 bit symbol, 32 QAM using a 5 bit symbol or 64 QAM using a 6 bit symbol. In particular, unlike the downstream channel used to transfer the downstream signal from the CMTS 110 to the CMs 120, since the upstream channel transmits a burst signal that is transferred over the same center frequency and bandwidth from the CMs 120 to the CMTS 110, each CM 120 needs to transmit the burst signal within one of a competition slot, a reserved slot, and a minute adjustment slot.
On the grounds stated above, the data over cable service Interface specification (DOCSIS) standard uses a request-permission method in order for the CMs 120 to obtain an opportunity to transmit data over the upstream channel and uses another request-permission method according to DOCSIS 1.x/2.0, DOCSIS 3.0, etc. Therefore, the CMs 120 request the CMTS 110 to allocate bandwidths if a packet arrives at an upstream transmission queue. The bandwidth allocation request is made by an independent request message, or is piggybacked during a data transmission, and is transferred to the CMTS 110.
FIG. 2A illustrates a conventional format of a request message 201 used by a CM of a DOCSIS 1.x/2.0 version to request a CMTS to allocate a bandwidth.
Referring to FIG. 2A, the conventional request message 201 includes 1 frame control (FC) information byte 210 indicating a type of a frame, 2 service ID (SID) information bytes 230, and 1 mini-slot number information byte 220 necessary for packet transmission.
FIG. 2B illustrates a conventional format of a queue-depth based request message 202 used by a CM of a DOCSIS 3.0 version to request a CMTS to allocate a bandwidth. Referring to FIG. 2B, the queue-depth based request message 202 includes 1 FC information byte 250, indicating a type of a frame, 2 SID information bytes 270, and 2 length information bytes 260 of a packet stored in an upstream transmission queue.
In particular, the CM of the DOCSIS 1.x/2.0 version requests an allocation of bandwidths using the number of mini-slots necessary for transmitting a packet when requesting the allocation of bandwidths. In this regard, the number of mini-slots includes a physical layer overhead necessary for transmitting the packet. The size of one mini-slot is determined as 2n times 6.25 μs (n=0, 1, . . . , m), and is defined in an upstream channel descriptor (UCD) message regarding each upstream channel. Thus, the CM needs to calculate the size of one mini-slot necessary for a packet transmission including the physical layer overhead in order to request the allocation of bandwidths.
However, the CM of the DOCSIS 3.0 version requests byte lengths of packets stored in the upstream transmission queue in order to transmit packets when requesting the allocation of bandwidths. The CMTS needs to calculate and allocate byte lengths stored in a queue requested by the CM and the number of mini-slots necessary for transmitting lengths of the physical layer overhead and a segment length necessary for the packet transmission.
FIG. 3 is a flowchart illustrating a method of determining the size of a bandwidth necessary for a packet transmission and requesting an allocation of bandwidths in a CM according to a DOCSIS standard. Referring to FIG. 3, it is examined whether a CM version is 1.x/2.0/3.0 (operations 302 and 303). If the CM version is 3.0, the requested bandwidth size is determined as the length of a packet stored in a queue (operation 310), and a resource-request message is transmitted (operation 350).
If the CM version is 2.0, advanced short data burst parameters are used to calculate the size of a necessary mini-slot (operation 330), and the calculated result value is compared with a maximum burst size (MBS) value from among the advanced short data burst parameters (operation 331). If the MBS value is greater than the calculated result value, the calculated result value is determined as the requested bandwidth size and the resource-request message is transmitted (operation 350). If the calculated result value is greater than the MBS value, advanced long data burst parameters are used to calculate the size of the necessary mini-slot (operation 332), and the calculated result value is compared with the MBS value among the advanced short data burst parameters (operation 333). If the calculated result value is greater than the MBS value, the calculated result value is determined as the requested bandwidth size and the resource-request message is transmitted (operation 350). If the MBS value is greater than the calculated result value, the requested bandwidth size is determined to be greater than the MBS value by 1 (operation 340), and the resource-request message is transmitted (operation 350).
If the CM version is 1.x, short data burst parameters are used to calculate the size of the necessary mini-slot (operation 320), and the calculated result value is compared with an MBS value among the short data burst parameters (operation 321). If the MBS value is greater than the calculated result value, the calculated result value is determined as the requested bandwidth size and the resource-request message is transmitted (operation 304). If the calculated result value is greater than the MBS value, long data burst parameters are used to calculate the size of the necessary mini-slot (operation 322), and the calculated result value is compared with the MBS value from among the short data burst parameters (operation 323). If the calculated result value is greater than the MBS value, the calculated result value is determined as the requested bandwidth size and the resource-request message is transmitted (operation 350). If the MBS value is greater than the calculated result value, the requested bandwidth size is determined to be greater than the MBS value by 1 (operation 340), and the resource-request message is transmitted (operation 350).
The CMTS requested by the CMs for the allocation of bandwidths transmits a mobile application part (MAP) message including information on the allocation of bandwidths to a downstream channel, and notifies each CM of information on a transmittable mini-slot that is necessary for data transmission.
FIG. 4 illustrates a format of a MAP message 400 that a CMTS transfers to CMs. Referring to FIG. 4, the MAP message 400 includes a media access control (MAC) management message header 410 indicating information on a destination MAC address, a source MAC address, and the MAC management message type/version, an upstream channel ID 1 byte 421 indicating information on an upstream channel used to allocate bandwidths by the MAP message 400, a UCD change counter 1 byte 422 indicating a UCD message to be used to transmit packets, the number of information elements (IEs) (1 byte) 423 indicating the number of IEs included in the MAP message, 1 reserved filed byte 424 that is not used, 4 allocation start time bytes 425 indicating an initial time for allocating bandwidths by the MAP message 400, 4 response time bytes 426 indicating a time for receiving a last resource-request message used to allocate bandwidths by the MAP message 400, transmission backoff start and end 427, and one or more IEs 430 that is information on the substantial allocation of bandwidths.
In particular, the IEs 430 include a 14 bit SID 431 indicating a type of a service to which a bandwidth is allocated, a 4 bit interval usage code (IUC) indicating information on a physical layer parameter used to transmit packets, and a 14 bit offset value 433 indicating information on a time for allocating bandwidths.
CMs receive the MAP message 400 from the CMTS, obtain information on mini-slot information allocated as an offset value in an IE regarding the same SID as an SID included in the resource-request message, and transmit packets using physical layer parameters defined in burst profiles indicated by an IUC.
CMs that receive the MAP message 400 must previously know the physical layer parameter in order to transmit packets by using the allocated bandwidths. In particular, a CM of the DOCSIS 1.x/2.0 version needs to calculate the size of requested bandwidths by using the physical layer parameter defined according to the burst characteristics in order to transmit the resource-request message. The DOCSIS standard defines fixed IUC values respectively corresponding to burst profiles in which the physical layer parameter is defined.
Table 1 includes the definition of IUC values allocated to each burst profile defined in the DOCSIS standard. Therefore, the DOCSIS standard defines 9 IUC values including Initial Maintenance, Periodic Maintenance, Request, Request/Data, Short Data, Long Data, Adv Short Data, Adv Long Data, and Adv Unsolicited Grant as shown in Table 1 below.
TABLE 1IntervalUsage Code(IUC)IE NameSID1RequestWith Any SID2Request/DataWith Multicast SID3Initial MaintenanceWith Broadcast orUnicast SID4Station MaintenanceWith Unicast SID5Short Data GrantWith Unicast SID6Long Data GrantWith Unicast SID7Null IEZero8Data AckWith Unicast SID9Advanced PHY Short Data GrantWith Unicast SID10 Advanced PHY Long Data GrantWith Unicast SID11 Advanced PHY UnsolicitedWith Unicast SIDGrant12~14ReservedWith Any SID15 ExpansionWith expanded IUC
Also, each burst profile included in Table 1 is provided to CMs via a UCD message as described above. The UCD message includes all parameters regarding one logical upstream channel.
FIG. 5A illustrates a format of a UCD message that a CMTS transfers to CMs. Referring to FIG. 5, the UCD message includes a MAC management message header 510 indicating information on a destination MAC address, a source MAC address, and the MAC management message type/version, 1 upstream channel ID byte 520 indicating information on an upstream channel relating to the UCD message, 1 UCD change counter byte 530 indicating a change in a previous UCD message, 1 mini-slot size byte 540 indicating the mini-slot size of the upstream channel, 1 downstream channel ID byte 550 indicating a downstream channel used to transmit the UCD message, channel parameter type/length/value (TLV) 560 indicating parameters of the upstream channel relating to the UCD message, burst descriptor TLV 570 indicating channel physical PHY parameters. There may be a plurality of burst descriptor TLVs according to each IUC value included in Table 1.
FIG. 5B illustrates burst descriptor TLVs according to each IUC value. Referring to FIG. 5B, the burst descriptor TVL includes 1 type byte 571 indicating a burst descriptor type, 1 length byte 572 indicating the whole length of PHY parameters according to one IUC value, 1 IUC byte indicating each IUC value 573, and a PHY parameter TLV 574 according to each IUC value. PHY parameter TLVs include PHY parameter information of an upstream channel such as a modulation technique, a preamble length, an MBS, protection time length, etc.
For example, Table 2 includes PHY parameter values of 5, 6, 9, 10, and 11 that are IUC values for transmitting user data in the DOCSIS standard. The UCD message including burst descriptors shown in Table 2 is transferred to all CMs via the same upstream channel. All CMs receive the UCD message, request the CMTS for resources, receive resources, and transmit data by using PHY parameter values of IUC values defined in a MAP message.
In particular, CMs of the DOCSIS 1.x version must use IUC values of 5 and 6, and CMs of the DOCSIS 2.0 version must use IUC values of 9 and 10 when requesting resources and transmitting data. Finally, since CMs of the DOCSIS 3.0 version request the size of a stored buffer when requesting resources, it is possible to use all IUC values of 5, 6, 9, and 10. In more detail, 5 burst profiles having IUC values of 5, 6, 9, 10, and 11 can transmit user data in the given DOCSIS standard, and furthermore, CMs of the DOCSIS 1.x/2.0 version can use 2 burst profiles having IUC values of 5, 6/9, and 10, respectively.
TABLE 2IUC Value (Define) PHY parameter(sub-type)5691011(Short)(Long)(AdvphyS)(AdvphyL)(AdvphyU)Modulation Type (1)22555Differential Encoding22222(2)Preamble Length (3)168192646464FEC Error Correction0x80xA0xC0x100xC(5)FEC Codeword Infor.0x4E0xDC0x4E0xDC0x4EBytes (6)Scrambler Seed (7)0x1520x1520x1520x1520x152Maximum Burst Size80800(8)Guard Time Size (9)88888Last Code word Length22222(10)Scrambler on/off (11)11111
The DOCSIS standard above supports 5 burst profiles, and CMs of the DOCSIS 1.x/2.0 version use 2 burst profiles to transmit user data. All CMs that use the same upstream channel use the same burst profile. Therefore, each CM transmits user data using upstream PHY parameters defined in burst profiles of the UCD message according to the size of user data to be transmitted irrespective of the transmission capability and upstream channel status, which reduces channel usage efficiency.
For example, in a HFC network constituting a CM A and a CM B of the DOCSIS 2.0 version that uses the same upstream channel, if the CM A can use a maximum 64 QAM/Low RS code and the CM B can use a maximum 16 QAM/High RS code during an upstream channel transmission, both CMs need to use an 16 QAM/Low RS code to transmit upstream data. Because both CMs can receive the same UCD message to use burst profiles in the UCD message, and a CMTS enables all CMs to transmit data by constituting and transmitting the UCD message.
There is a method of increasing physical layer flexibility in a CM. During an initial process of the CM and a CMTS, the CM determines whether to operate in a dynamic burst profile mode, and the CMTS provides the CM with more burst profiles and supports the burst profiles. However, the method can provide a maximum of 8 burst profiles since IUC values of a MAP message can be 4 bits, and IUC values of 1, 2, 3, 4, 7, and 8 are reserved in the DOCSIS standard.
Furthermore, since CMs that do not operate in the dynamic burst profile mode are designed to operate according to the DOCSIS standard, CMs have a problem of allocating burst profiles irrespective of the upstream channel status. Finally, the above method does not allocates burst profiles according to the upstream channel status.